DurableHttpRequest.Timeout is documented as the total timeout for the HTTP request and any asynchronous polling, but CallHttpAsync never reads/enforces it. As written, the polling loop can run indefinitely if the endpoint keeps returning 202. Consider tracking a deadline (based on context.CurrentUtcDateTime) and stopping/throwing once the timeout is exceeded.

The Location header used for 202 polling may legally be a relative URI (e.g. /status/123). new Uri(locationUrl) will produce a relative Uri, and the subsequent HTTP activity call will fail unless the HttpClient has a BaseAddress. Consider resolving against the original request URI (e.g., new Uri(request.Uri, locationUrl)) before constructing the poll request.

Retry-After can be either delta-seconds or an HTTP-date. The polling logic only supports integer seconds, so valid HTTP-date values will be ignored and fall back to the default interval. Consider also parsing the HTTP-date form to match standard Retry-After semantics.

BuildHttpRequest always creates StringContent with media type application/json when request.Content is set. This can override user intent (e.g., form data, plain text, custom Content-Type header) and can also lead to duplicated/contradictory Content-Type headers. Consider not hard-coding the media type here and instead honoring an explicit Content-Type header (or leaving it unset).

When HttpRetryOptions is provided but FirstRetryInterval is left at its default (TimeSpan.Zero), retries will occur back-to-back with no delay (and exponential backoff will never increase it from zero). Consider validating FirstRetryInterval when MaxNumberOfAttempts > 1, or applying a small, non-zero default delay to avoid tight retry loops.

HttpHeadersConverter.Read does not handle JsonTokenType.Null. If JSON contains "headers": null, the converter returns an empty dictionary, which changes the meaning for nullable Headers properties (callers cannot distinguish null vs empty) and may break wire-compat expectations. Consider supporting null explicitly (e.g., use a nullable converter JsonConverter<IDictionary<string,string>?> and return null for JsonTokenType.Null).

The XML doc comment says this converter “handles serialization only” and that “deserialization is not supported”, but Read(...) is implemented and returns a ManagedIdentityTokenSource. Please update the documentation to reflect the actual behavior (or adjust the implementation to match the documented intent).

UseHttpActivities() unconditionally calls registry.AddActivity(...). Since DurableTaskRegistry.AddActivity throws if the name is already registered, calling UseHttpActivities() in an app that has already registered BuiltIn::HttpActivity (or calling UseHttpActivities() twice) will throw. Consider making registration idempotent or at least surfacing a clearer exception/message about the duplicate registration scenario.

The remarks state “If an IHttpClientFactory is registered in the service collection, a named client ... is used”, but UseHttpActivities() always registers IHttpClientFactory via AddHttpClient(...) and then requires it via GetRequiredService<IHttpClientFactory>(). Consider updating the remarks to reflect that this extension always uses the named client and will fail if the DI registration is removed/overridden.